Toradex Torizon 플랫폼과 ROS 2 Humble을 활용한 산업용 AMR 개발

1. Torizon과 ROS 2를 활용한 산업용 AMR 개발의 새로운 패러다임

1.1 현대 AMR 개발의 도전 과제와 Torizon 플랫폼의 부상

자율 이동 로봇(AMR) 시장이 급성장함에 따라, 개발자들은 단순한 프로토타입을 넘어 상업적으로 신뢰할 수 있고 확장 가능한 제품을 출시해야 하는 압박에 직면해 있다. 현대 AMR 개발은 하드웨어의 다양성, 임베디드 리눅스 환경의 복잡성, 강화되는 보안 요구사항, 그리고 배포 후 지속적인 소프트웨어 업데이트 및 유지보수라는 다층적인 도전 과제를 안고 있다.1 특히, Yocto Project와 같은 임베디드 리눅스 빌드 시스템은 강력한 커스터마이징 기능을 제공하지만, 학습 곡선이 가파르고 빌드 및 유지보수에 상당한 전문 인력과 시간을 요구한다. 이는 신속한 시장 진입을 목표로 하는 기업에게 큰 부담으로 작용한다.

이러한 배경 속에서 Toradex의 Torizon 플랫폼은 산업용 임베디드 시스템, 특히 AMR 개발의 복잡성을 해결하기 위한 통합 솔루션으로 부상하였다. Torizon은 검증된 하드웨어(SoM, System on Module), 산업용 리눅스 운영체제, 현대적인 개발 도구, 그리고 원격 업데이트 및 장치 모니터링 서비스를 하나의 패키지로 제공한다.1 이 플랫폼의 핵심 철학은 개발자가 운영체제 빌드, BSP(Board Support Package) 관리, 보안 패치 적용과 같은 저수준의 인프라 구축에 쏟는 노력을 최소화하고, 로봇의 핵심 기능인 애플리케이션 개발에 집중할 수 있도록 지원하는 것이다.4 Torizon은 전통적인 임베디드 개발의 패러다임을 넘어, 클라우드 및 웹 개발 분야에서 검증된 DevOps(Development and Operations) 접근법을 엣지 컴퓨팅 환경으로 확장하려는 시도이다. OTA(Over-the-Air) 업데이트, 플릿(Fleet) 관리, CI/CD(Continuous Integration/Continuous Deployment) 파이프라인 통합과 같은 기능들은 Torizon이 단순한 운영체제가 아닌, AMR 제품의 전체 수명 주기를 관리하는 ’임베디드 DevOps 플랫폼’임을 시사한다.1

1.2 컨테이너 기술이 로보틱스 개발 및 배포에 미치는 영향

Torizon 플랫폼의 기술적 근간을 이루는 것은 Docker 컨테이너 기술이다. 컨테이너는 애플리케이션과 그 모든 의존성을 격리된 환경에 패키징하여, 개발, 테스트, 배포 환경 간의 일관성을 보장한다.4 이러한 특성은 복잡한 소프트웨어 스택을 가진 로보틱스 개발에 다음과 같은 혁신적인 변화를 가져온다.

첫째, 의존성 관리의 단순화. ROS(Robot Operating System) 애플리케이션은 수많은 라이브러리와 패키지에 의존한다. 컨테이너는 이러한 의존성을 이미지 내에 고정시켜, 호스트 운영체제의 상태와 무관하게 애플리케이션이 항상 동일하게 동작하도록 보장한다. 이는 “내 컴퓨터에서는 동작했는데, 로봇에서는 안 된다“와 같은 고질적인 문제를 근본적으로 해결한다.4

둘째, 모듈성과 재사용성 증대. ROS 2의 노드(Node) 기반 분산 아키텍처는 컨테이너의 마이크로서비스 개념과 자연스럽게 부합한다. SLAM, 내비게이션, 비전 처리, 모터 제어 등 각 기능을 별도의 컨테이너로 분리하여 개발하고 배포할 수 있다. 이는 각 기능의 독립적인 업데이트를 가능하게 하고, 시스템 전체의 안정성을 높이며, 검증된 기능 모듈의 재사용을 촉진한다.

셋째, 개발과 배포의 간극 해소. 개발자는 자신의 PC에서 컨테이너 기반으로 애플리케이션을 개발하고, 동일한 컨테이너 이미지를 대상 AMR에 그대로 배포할 수 있다. 이는 개발 환경과 실제 운영 환경의 차이로 인해 발생하는 버그를 최소화하고, 배포 프로세스를 자동화하여 신뢰성을 높인다.

1.3 Torizon과 ROS 2 Humble 조합의 시너지와 전략적 가치 분석

Torizon의 산업용 등급 플랫폼과 ROS 2의 강력한 로봇 미들웨어 프레임워크의 결합은 상용 AMR 개발에 있어 강력한 시너지를 창출한다. 특히 ROS 2 Humble Hawksbill은 2027년 5월까지 지원되는 장기 지원(LTS) 릴리즈로서, 상용 제품 개발에 요구되는 안정성과 긴 수명 주기를 제공한다.7

이 조합의 전략적 가치는 다음과 같이 요약할 수 있다.

• 신속한 시장 출시 (Faster Time-to-Market): Torizon은 사전 구성된 산업용 리눅스와 개발 도구를 제공하여 OS 빌드 및 설정 시간을 수개월에서 수일로 단축시킨다. ROS 2는 SLAM, 내비게이션, 조작(Manipulation) 등 방대한 오픈소스 알고리즘과 도구 생태계를 제공하여 개발자가 바퀴를 재발명할 필요 없이 핵심 기능 구현에 집중하게 한다.4

• 높은 호환성과 유연성: ROS 2 Humble은 Ubuntu 22.04 (Jammy Jellyfish)를 Tier 1 플랫폼으로 공식 지원한다.8 Torizon은 Debian 기반의 컨테이너 환경을 제공하므로 2, Ubuntu 22.04를 기반으로 하는 공식 ROS 2 Humble Docker 이미지를 거의 수정 없이 활용할 수 있다. 이는 완벽에 가까운 호환성을 보장하며, 개발자는 Docker Hub에 있는 수많은 사전 빌드된 ROS 컨테이너를 즉시 활용할 수 있다.4

• 상용 수준의 신뢰성 및 보안: Torizon은 읽기 전용 루트 파일 시스템, 하드웨어 보안 기능 활용, 자동차 산업 표준인 Uptane 기반의 보안 OTA 업데이트 기능을 통해 플랫폼의 무결성과 보안을 강화한다.1 ROS 2 역시 DDS(Data Distribution Service) 보안 플러그인을 통해 통신 암호화, 인증, 접근 제어 등 강화된 보안 기능을 제공한다. 이 두 가지가 결합되어 AMR 시스템의 엔드투엔드 보안을 구축할 수 있다.

결론적으로, Torizon과 ROS 2 Humble의 조합은 AMR 개발의 기술적 복잡성과 상용화의 장벽을 동시에 낮추는 강력한 솔루션이다. 이는 개발자가 혁신적인 로봇 애플리케이션을 더 빠르고, 더 안정적이며, 더 안전하게 시장에 출시할 수 있도록 지원하는 전략적 이점을 제공한다.

2. Torizon 플랫폼 아키텍처 심층 분석: AMR을 위한 안정적 기반

2.1 Torizon OS의 핵심 구성 요소: 최소한의 호스트 OS와 컨테이너 런타임

Torizon OS는 전통적인 데스크톱이나 서버용 리눅스 배포판과 근본적으로 다른 아키텍처를 가진다. 그 핵심은 **최소주의(Minimalism)**에 있다. 호스트 운영체제는 오직 컨테이너를 안정적으로 실행하고 시스템을 관리하는 데 필수적인 구성 요소만을 포함한다.6 여기에는 리눅스 커널, 부트로더, Docker와 같은 컨테이너 런타임, 그리고 OTA 업데이트를 담당하는 클라이언트(Aktualizr) 등이 해당한다.6

주목할 점은 Torizon OS의 기본 시스템에는 apt나 dnf와 같은 패키지 관리자가 존재하지 않는다는 것이다.6 이는 의도적인 설계 결정으로, 모든 애플리케이션 소프트웨어와 그 의존성 라이브러리들은 반드시 컨테이너 내부에 패키징되어야 함을 의미한다. 이러한 접근 방식은 다음과 같은 중요한 이점을 제공한다.

1. 호스트 OS의 불변성(Immutability): 호스트 시스템에 임의의 패키지가 설치되는 것을 원천적으로 차단함으로써, OS의 상태가 예측 가능하고 일관되게 유지된다. 이는 시스템의 안정성을 극대화하고, 특정 패키지 업데이트로 인해 전체 시스템이 불안정해지는 위험을 방지한다.

2. 명확한 책임 분리: 플랫폼(OS)과 애플리케이션의 책임이 명확하게 분리된다. Toradex는 안정적인 플랫폼을 제공하고, 개발자는 자신의 애플리케이션을 컨테이너로 만들어 그 위에서 실행하기만 하면 된다.

3. 보안 강화: 공격 표면(attack surface)이 최소화된다. 불필요한 서비스나 라이브러리가 호스트에 설치되어 있지 않으므로, 잠재적인 보안 취약점이 줄어든다.

이러한 구조는 AMR과 같이 높은 신뢰성이 요구되는 시스템에 매우 적합하다. 로봇의 핵심 기능은 컨테이너 안에서 동작하며, 기반이 되는 운영체제는 견고하고 변하지 않는 반석과 같은 역할을 수행한다.

2.2 보안 및 안정성: 읽기 전용 루트 파일 시스템, Uptane 기반의 OTA 업데이트

Torizon은 상용 제품에 요구되는 높은 수준의 보안과 안정성을 확보하기 위해 두 가지 핵심 기술을 채택하고 있다: 읽기 전용 루트 파일 시스템과 Uptane 기반의 보안 OTA 업데이트이다.

읽기 전용 루트 파일 시스템(Read-only Root Filesystem): Torizon OS의 루트 파일 시스템(/)은 기본적으로 읽기 전용으로 마운트된다.3 이는 시스템의 무결성을 보장하는 강력한 메커니즘이다. 만약 악성 소프트웨어가 시스템에 침투하더라도 시스템 핵심 파일을 수정하거나 변조할 수 없다. 또한, 예기치 않은 전원 차단이나 소프트웨어 오류로 인해 파일 시스템이 손상될 위험을 크게 줄여준다. 애플리케이션 데이터나 설정과 같이 변경이 필요한 파일들은 별도의 쓰기 가능한 파티션(예: /var)에 저장되어 관리된다.

Uptane 기반의 OTA 업데이트: 현장에 배포된 수많은 AMR을 유지보수하고 업데이트하는 것은 매우 중요한 과제이다. Torizon은 이를 위해 OSTree와 Uptane 프레임워크를 결합한 강력하고 안전한 OTA 업데이트 솔루션을 제공한다.1

• OSTree: ’파일 시스템을 위한 Git’으로 비유되는 OSTree는 전체 루트 파일 시스템을 원자적(atomic)으로 업데이트한다. 업데이트 과정 중에 전원이 차단되거나 네트워크 연결이 끊어지더라도, 시스템은 이전의 정상 작동 상태로 안전하게 롤백할 수 있다. 이는 업데이트 실패로 인해 장치가 ‘벽돌(bricking)’ 상태가 되는 것을 방지하는 핵심 기술이다.6

• Uptane: 자동차 산업의 보안 요구사항을 충족하기 위해 설계된 Uptane은 현재 가장 안전한 소프트웨어 업데이트 프레임워크 중 하나로 평가받는다. 다중 서명, 역할 분리, 메타데이터 검증 등 정교한 보안 메커니즘을 통해 업데이트 패키지의 무결성과 신뢰성을 보장하며, 서버가 해킹당하더라도 악의적인 업데이트가 장치에 설치되는 것을 방지한다.1

이 두 기술의 결합은 개발자가 안심하고 필드에 있는 AMR 플릿 전체에 보안 패치나 새로운 기능을 배포할 수 있는 강력한 기반을 제공한다.

2.3 실시간(Real-Time) 지원: PREEMPT_RT 패치와 그 의미

AMR의 모터 제어, 센서 데이터의 동기화, 긴급 정지 시스템 등 일부 작업은 정해진 시간 내에 반드시 완료되어야 하는 실시간(real-time) 요구사항을 가진다. 일반적인 리눅스 커널은 평균 처리량에 최적화되어 있어, 특정 작업의 실행 시간이 예측 불가능하게 지연(latency)될 수 있다.

이러한 문제를 해결하기 위해 Torizon은 PREEMPT_RT(Real-Time) 패치가 적용된 커널을 선택적으로 제공한다.2 PREEMPT_RT는 리눅스 커널을 완전 선점형(fully preemptible)으로 만들어, 높은 우선순위를 가진 실시간 작업이 커널 코드 실행 중에도 다른 작업을 중단시키고 CPU를 점유할 수 있도록 한다. 이는 시스템의 최대 지연 시간(worst-case latency)을 크게 줄여, 작업 실행의 결정론성(determinism)을 향상시킨다.10

Toradex 커뮤니티의 논의에 따르면, Torizon의 PREEMPT_RT 이미지는 기본적인 테스트를 거쳤으며, 유휴 상태에서 cyclictest와 같은 도구를 통해 양호한 실시간 성능을 보이는 것으로 확인되었다.11 하지만 Toradex는 모든 가능한 워크로드에 대해 완전한 검증을 보장하지는 않으며, 개발자가 자신의 특정 애플리케이션 환경에서 실시간 성능을 직접 테스트하고 검증할 것을 권장한다. 그럼에도 불구하고, PREEMPT_RT 커널의 제공은 결정론적 성능이 필수적인 AMR의 제어 루프나 안전 관련 기능을 구현하는 데 있어 매우 중요한 출발점을 제공한다.

2.4 Torizon Cloud를 통한 디바이스 플릿(Fleet) 관리 및 모니터링

단일 AMR 프로토타입을 개발하는 것과 수백, 수천 대의 AMR 플릿을 상업적으로 운영하는 것은 전혀 다른 차원의 문제이다. Torizon Cloud는 후자의 문제를 해결하기 위해 설계된 SaaS(Software as a Service) 플랫폼이다.5

Torizon Cloud는 다음과 같은 핵심 기능을 제공한다:

• 디바이스 및 플릿 관리: 현장에 배포된 모든 장치를 중앙에서 등록하고 그룹으로 관리할 수 있다. 각 장치의 상태, 설치된 소프트웨어 버전 등을 한눈에 파악할 수 있다.

• 소프트웨어 패키지 관리 및 원격 업데이트: 개발자가 빌드한 컨테이너 이미지를 Torizon Cloud에 업로드하고, 특정 장치 또는 플릿 전체에 OTA 업데이트를 안전하게 배포할 수 있다. 업데이트는 앞서 설명한 Uptane 프레임워크를 통해 보안이 보장된다.

• 디바이스 모니터링: CPU 사용량, 메모리 점유율, 디스크 공간, 네트워크 트래픽 등 장치의 핵심 성능 지표를 원격으로 모니터링할 수 있다.1 이를 통해 잠재적인 문제를 사전에 감지하고, 장애 발생 시 원인을 신속하게 파악할 수 있다.

• 원격 접근: 보안 터널을 통해 현장의 장치에 원격으로 SSH 접속하여 문제를 진단하고 해결할 수 있다.

이러한 기능들은 AMR 제품의 전체 수명 주기 비용(TCO, Total Cost of Ownership)을 크게 절감하는 효과를 가져온다. 개발팀이 직접 이러한 플릿 관리 인프라를 구축하는 데 드는 막대한 시간과 비용을 절약할 수 있으며, 이는 Torizon이 단순한 OS를 넘어 AMR 제품의 장기적인 운영과 유지보수를 지원하는 전략적 플랫폼으로 포지셔닝되는 이유이다.

3. 개발 환경 구축 및 워크플로우 최적화

3.1 VS Code와 Torizon IDE Extension을 활용한 통합 개발 환경 설정

효율적인 개발 워크플로우는 AMR 개발의 생산성을 결정하는 핵심 요소이다. Toradex는 널리 사용되는 통합 개발 환경(IDE)인 Visual Studio Code(VS Code)를 위한 Torizon IDE Extension을 제공하여 개발 과정을 대폭 간소화한다.12 이 확장은 기존의 복잡한 임베디드 크로스-컴파일 및 배포 과정을 자동화하여, 개발자가 애플리케이션 로직에만 집중할 수 있도록 돕는다.

Torizon IDE Extension의 주요 기능은 다음과 같다:

• 장치 자동 탐색 및 연결: 동일 네트워크에 있는 Torizon 장치를 자동으로 검색하고, 간단한 인증 절차를 통해 VS Code 내에서 원격 장치에 연결할 수 있다.14

• 컨테이너 배포 자동화: VS Code 내에서 프로젝트를 빌드하면, 확장은 자동으로 Docker 이미지를 생성하고 이를 원격 Torizon 장치로 전송하여 컨테이너를 실행한다. 개발자는 복잡한 Docker CLI 명령어를 알 필요가 없다.13

• 원격 디버깅 통합: C/C++ 및 Python으로 작성된 ROS 2 노드를 원격으로 디버깅할 수 있다. VS Code의 강력한 디버깅 인터페이스를 사용하여 Torizon 장치에서 실행 중인 컨테이너 내부의 코드에 중단점(breakpoint)을 설정하고, 변수를 검사하며, 코드를 한 줄씩 실행할 수 있다.13

• 템플릿 기반 프로젝트 생성: C/C++, Python 등 다양한 언어와 빌드 시스템(CMake, Makefile)을 위한 프로젝트 템플릿을 제공하여, ROS 2 애플리케이션 개발을 신속하게 시작할 수 있도록 지원한다.

이 확장은 VS Code의 공식 Docker 확장과 긴밀하게 연동하여 동작하며, 개발자에게 컨테이너화된 개발 환경의 투명성과 제어권을 제공한다. 이를 통해 개발자는 필요에 따라 Dockerfile이나 docker-compose.yml 파일을 직접 수정하여 개발 환경을 유연하게 맞춤 설정할 수 있다.13

3.2 ROS 2 Humble 개발을 위한 Dockerfile 및 docker-compose.yml 설계 전략

Torizon 환경에서 ROS 2 애플리케이션을 개발하고 배포하는 핵심은 Dockerfile과 docker-compose.yml 파일을 효과적으로 설계하는 것이다.

3.2.1 Dockerfile 설계

Dockerfile은 ROS 2 개발 및 실행 환경을 정의하는 설계도이다. AMR 개발을 위한 Dockerfile은 일반적으로 다음과 같은 단계를 포함한다.

1. 기반 이미지 선택: Open Robotics에서 제공하는 공식 ROS 2 Humble 이미지를 기반으로 시작하는 것이 가장 효율적이다. 애플리케이션에 GUI 도구(예: RViz2)가 필요하다면 osrf/ros:humble-desktop을, 필요 없다면 더 가벼운 ros:humble 이미지를 선택한다.4

2. ROS 2 패키지 설치: apt-get install 명령어를 사용하여 ros-humble-navigation2, ros-humble-slam-toolbox, ros-humble-ros2-control, ros-humble-realsense2-camera 등 AMR에 필요한 핵심 ROS 2 패키지들을 설치한다.16

3. 워크스페이스 설정: colcon 빌드를 위한 ROS 2 워크스페이스(예: /ros2_ws)를 생성하고, 애플리케이션 소스 코드를 컨테이너 내부로 복사한다 (COPY 명령어).

4. 의존성 설치: rosdep install 명령어를 사용하여 워크스페이스 내 패키지들의 모든 시스템 의존성을 자동으로 설치한다. 이는 개발자가 수동으로 라이브러리를 찾는 수고를 덜어준다.19

5. 빌드 및 환경 설정: colcon build 명령어를 실행하여 워크스페이스를 빌드하고, 컨테이너가 시작될 때마다 source /ros2_ws/install/setup.bash 명령어가 실행되도록 ENTRYPOINT 또는 CMD를 설정하여 ROS 2 환경을 활성화한다.20

3.2.2 docker-compose.yml 설계

docker-compose.yml 파일은 다중 컨테이너 애플리케이션을 정의하고 실행하기 위한 도구이다. AMR 시스템은 여러 ROS 2 노드와 서비스로 구성되므로, docker-compose를 사용하면 전체 시스템을 하나의 파일로 관리하고 일관되게 실행할 수 있다.15

AMR 개발을 위한 docker-compose.yml 설계 시에는 개발, 디버깅, 배포 등 다양한 목적에 따라 서비스를 분리하는 전략이 유용하다. 이는 불필요한 도구가 포함되지 않은 가벼운 배포 이미지를 유지하면서도, 개발 시에는 풍부한 기능을 활용할 수 있게 한다.

이러한 서비스 분리 전략은 docker-compose.yml 파일의 유연성을 극대화한다. 개발자는 docker-compose up dev-container 명령으로 개발 환경을 시작하고, CI/CD 파이프라인은 docker-compose build amr-app 명령으로 배포용 이미지를 생성할 수 있다.

3.3 Colcon 빌드 시스템과 VS Code tasks.json 연동을 통한 빌드 자동화

colcon은 ROS 2의 표준 빌드 도구이다. VS Code의 tasks.json 파일을 설정하면 colcon 명령어를 IDE에 통합하여 빌드 프로세스를 자동화하고 가속화할 수 있다. .vscode/tasks.json 파일에 다음과 같은 작업을 정의할 수 있다.21

{
"version": "2.0.0",
"tasks":
},
{
"label": "colcon test",
"type": "shell",
"command": "colcon test && colcon test-result --all",
"group": {
"kind": "test",
"isDefault": true
}
}
],
"inputs":
}

이 설정은 다음과 같은 기능을 제공한다:

• 기본 빌드 작업: Ctrl+Shift+B 단축키를 누르면 전체 워크스페이스를 빌드한다. --symlink-install 옵션은 Python 코드나 리소스 파일 변경 시 재빌드 없이 즉시 반영되도록 하며, -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 옵션은 C++ 인텔리센스의 정확도를 높이기 위한 compile_commands.json 파일을 생성한다.21

• 단일 패키지 빌드: 특정 패키지만 선택하여 빌드하는 작업을 제공하여, 대규모 워크스페이스에서 작업할 때 빌드 시간을 단축시킨다.

• 테스트 작업: 전체 워크스페이스의 테스트를 실행하고 결과를 요약하여 보여준다.

3.4 원격 디버깅 및 컨테이너 배포 워크플로우

VS Code와 Torizon IDE Extension을 활용한 개발 사이클은 매우 빠르고 반복적이다.

1. 코드 수정: 개발자는 로컬 PC의 VS Code에서 ROS 2 노드의 C++ 또는 Python 소스 코드를 수정한다.

2. 빌드: Ctrl+Shift+B 단축키를 눌러 tasks.json에 정의된 colcon build 작업을 실행한다. 이 빌드 과정은 개발 컨테이너 내부에서 실행될 수 있다.

3. 배포: Torizon IDE Extension의 ‘Deploy’ 버튼을 클릭하거나 관련 작업을 실행하면, 확장 프로그램이 업데이트된 애플리케이션을 포함하는 Docker 이미지를 다시 빌드하여 Torizon 장치에 배포하고 컨테이너를 재시작한다.

4. 디버깅: VS Code의 ‘Run and Debug’ 탭에서 미리 설정된 ‘Attach to Remote Container’ 구성을 실행한다. 디버거가 원격 장치의 컨테이너 내부에서 실행 중인 ROS 2 노드 프로세스에 연결되고, 개발자는 VS Code 내에서 직접 중단점을 설정하고 디버깅을 시작할 수 있다.13

이러한 통합된 워크플로우는 전통적인 임베디드 개발에서 흔히 발생하는 크로스-컴파일 툴체인 설정, 수동 파일 전송, 원격 gdb 실행 등의 번거로운 과정을 완전히 자동화하여 개발자의 생산성을 극대화한다.

4. ROS 2 Humble 기반 AMR 소프트웨어 아키텍처 설계

성공적인 AMR 개발을 위해서는 견고하고 확장 가능한 소프트웨어 아키텍처를 설계하는 것이 필수적이다. ROS 2는 이러한 아키텍처를 구축하기 위한 강력한 프레임워크를 제공하며, 특히 하드웨어 제어, 센서 통합, 자율 주행 기능 구현에 있어 표준화된 접근 방식을 제시한다.

4.1 하드웨어 추상화 계층: ros2_control을 이용한 구동계 통합

ros2_control은 ROS 2 생태계의 표준 하드웨어 제어 프레임워크이다.24 이 프레임워크의 핵심 목표는 로봇의 하드웨어(액추에이터, 센서)와 고수준의 제어 알고리즘(컨트롤러)을 분리하는 것이다.26 이를 통해 특정 모터 드라이버나 인코더에 종속적인 코드를 하드웨어 인터페이스 계층에 국한시키고, 궤적 추종이나 속도 제어와 같은 일반적인 제어 알고리즘은 어떤 하드웨어에서든 재사용할 수 있게 된다. 이러한 ‘책임의 분리’ 원칙은 소프트웨어의 모듈성과 유지보수성을 극대화한다.

ros2_control 아키텍처는 세 가지 주요 컴포넌트로 구성된다:

1. 하드웨어 인터페이스 (Hardware Interface): 로봇의 물리적 하드웨어와 직접 통신하는 플러그인 형태의 라이브러리이다. 이 컴포넌트는 모터 드라이버에 명령(예: 목표 속도)을 보내고, 하드웨어로부터 상태(예: 현재 바퀴 각도, 속도)를 읽어오는 역할을 담당한다. 개발자는 자신의 로봇 하드웨어에 맞는 하드웨어 인터페이스를 C++로 직접 구현해야 한다.26

2. 컨트롤러 (Controller): 특정 제어 로직을 수행하는 재사용 가능한 컴포넌트이다. 예를 들어, diff_drive_controller는 차동 구동 로봇의 기구학을 기반으로 로봇 전체의 선속도 및 각속도 명령(geometry_msgs/msg/Twist)을 양쪽 바퀴의 목표 속도로 변환하는 역할을 한다.28

3. 컨트롤러 관리자 (Controller Manager): 하드웨어 인터페이스와 컨트롤러를 연결하고 관리하는 핵심 노드이다. 컨트롤러 관리자는 로봇의 URDF(Unified Robot Description Format) 파일에 정의된 정보를 바탕으로 하드웨어 리소스를 로드하고, 사용자의 요청에 따라 컨트롤러를 동적으로 시작하거나 중지시키는 역할을 수행한다.26

AMR 개발에서는 일반적으로 diff_drive_controller가 사용된다. 이 컨트롤러는 하드웨어 인터페이스로부터 각 바퀴의 현재 상태(위치 또는 속도)를 피드백 받아 로봇의 현재 위치와 속도를 추정하는 주행 기록계(Odometry) 정보를 계산하고, 이를 ROS 2 네트워크에 발행(tf 및 nav_msgs/msg/Odometry 토픽)하는 기능까지 포함하고 있어 내비게이션 스택과의 연동이 용이하다.28

4.2 센서 인터페이스 및 드라이버 통합

AMR은 주변 환경을 인식하기 위해 다양한 센서를 사용한다. ROS 2 생태계는 널리 사용되는 센서들을 위한 수많은 드라이버 패키지를 제공하며, 이를 통해 센서 데이터를 표준화된 ROS 2 메시지 형태로 쉽게 얻을 수 있다. AMR 개발에 필수적인 센서와 관련 ROS 2 Humble 드라이버는 다음과 같다.

• LiDAR (Light Detection and Ranging): 2D 또는 3D LiDAR는 SLAM(Simultaneous Localization and Mapping)과 장애물 회피의 핵심 센서이다.

• Slamtec RPLIDAR, YDLIDAR: 저가형 2D LiDAR 시장에서 널리 사용되며, 각각 rplidar_ros와 ydlidar_ros2_driver 패키지를 통해 ROS 2를 지원한다.29

• SICK, Ouster: 산업용 등급의 고성능 LiDAR 제조사로, 공식 ROS 2 드라이버를 제공하여 안정적인 데이터 수집을 보장한다.29

• LiDAR 드라이버는 일반적으로 주변 환경의 거리 정보를 sensor_msgs/msg/LaserScan(2D) 또는 sensor_msgs/msg/PointCloud2(3D) 메시지 형태로 발행한다.

• IMU (Inertial Measurement Unit): 가속도계와 자이로스코프를 포함하는 IMU는 로봇의 각속도와 선형 가속도를 측정하여 주행 기록계의 정확도를 보정하는 데 중요한 역할을 한다.

• Bosch BNO055, SBG Systems 등 다양한 IMU 칩셋을 위한 ROS 2 드라이버가 커뮤니티를 통해 제공된다.29

• IMU 드라이버는 측정된 데이터를 sensor_msgs/msg/Imu 메시지 형태로 발행한다.

• 카메라 (Camera): RGB 카메라는 시각적 인식, 객체 탐지, vSLAM(Visual SLAM) 등에 사용되며, 깊이(Depth) 카메라는 3D 환경 인식과 장애물 회피에 활용된다.

• Intel RealSense: 깊이 카메라 시장의 선두주자로, realsense2_camera 패키지를 통해 ROS 2 Humble을 완벽하게 지원한다. 이 패키지는 RGB, 깊이, 적외선 이미지뿐만 아니라, 정합된 포인트 클라우드와 IMU 데이터까지 발행하는 포괄적인 기능을 제공한다.18

• 일반 USB 카메라: usb_cam과 같은 패키지를 사용하여 표준 UVC(USB Video Class) 카메라를 ROS 2 시스템에 쉽게 통합할 수 있다.29

이러한 센서 드라이버들은 Torizon 환경의 Dockerfile에 ros-humble-<package-name> 형태로 추가하여 설치하며, docker-compose.yml 파일에서 해당 센서의 USB 또는 시리얼 장치 파일(예: /dev/video0, /dev/ttyUSB0)에 대한 접근 권한을 컨테이너에 부여해야 한다.

4.3 SLAM 및 내비게이션 스택 (Nav2) 구성

수집된 센서 데이터를 바탕으로 로봇이 스스로 위치를 파악하고 목표 지점까지 자율적으로 주행하기 위해서는 SLAM과 내비게이션 스택이 필요하다.

4.3.1 slam_toolbox를 이용한 지도 작성 및 위치 추정

slam_toolbox는 ROS 2를 위한 강력하고 유연한 SLAM 솔루션이다.35 Karto 그래픽 SLAM 알고리즘을 기반으로 하며, 다음과 같은 특징을 가진다.

• 비동기 및 동기 모드: online_async_launch.py를 사용하면 실시간으로 지도를 생성하며, online_sync_launch.py는 더 높은 정확도를 위해 동기적으로 처리한다.

• 평생 매핑 (Lifelong Mapping): 기존에 생성된 지도를 불러와 탐색을 계속하거나, 새로운 환경을 기존 지도에 추가하는 것이 가능하다. 이는 로봇이 시간이 지남에 따라 변화하는 환경에 적응할 수 있게 해준다.35

• 지도 저장 및 로딩: 생성된 지도를 nav_msgs/OccupancyGrid 형태로 저장하고, 내비게이션을 위해 다시 불러올 수 있다.

slam_toolbox는 LiDAR 데이터(/scan)와 tf 변환 정보(odom -> base_link)를 입력받아, 지도(/map)와 지도 상에서 로봇의 위치(map -> odom tf 변환)를 출력한다.

4.3.2 Nav2 스택을 이용한 자율 주행

Nav2(Navigation 2)는 ROS 1의 내비게이션 스택을 계승하여 ROS 2를 위해 완전히 재설계된 차세대 자율 주행 프레임워크이다.37 Nav2는 단일 노드가 아닌, 각각 특정 작업을 수행하는 여러 서버 노드들의 집합으로 구성된 고도로 모듈화된 아키텍처를 채택하고 있다.

Nav2의 핵심 컴포넌트는 다음과 같다:

• BT Navigator Server: 행동 트리(Behavior Tree)를 기반으로 전체 내비게이션 작업을 조율하는 최상위 컨트롤러이다. “경로를 계획하고, 경로를 따라가고, 문제가 생기면 복구 행동을 수행하라“와 같은 복잡한 로직을 행동 트리로 정의한다.

• Planner Server: 전역 경로 계획을 담당한다. 현재 로봇의 위치와 목표 지점이 주어지면, 지도를 바탕으로 장애물을 피해 목표까지 도달하는 최적의 경로를 계산한다. DWA, A* 등 다양한 알고리즘을 플러그인 형태로 사용할 수 있다.

• Controller Server: 지역 경로 계획 및 속도 명령 생성을 담당한다. Planner가 생성한 전역 경로를 따라가면서, 실시간으로 센서 데이터를 확인하여 장애물을 회피하고 로봇의 모터에 전달할 속도 명령(Twist 메시지)을 계산한다.

• Recovery Server: 로봇이 길을 잃거나 장애물에 갇혔을 때 수행할 복구 행동(예: 제자리 회전, 후진)을 담당한다.

이 모든 서버들은 **생명주기 관리 노드(Lifecycle Managed Nodes)**로 구현되어 있다. 이는 노드들이 unconfigured, inactive, active, finalized와 같은 표준화된 상태를 가지며, 외부에서 이 상태들을 제어할 수 있음을 의미한다. 이를 통해 전체 내비게이션 시스템을 체계적으로 시작, 중지, 재설정할 수 있어 시스템의 안정성과 견고성이 크게 향상된다. 이는 예측 불가능한 상황이 발생할 수 있는 실제 산업 환경에서 AMR을 운영하는 데 있어 매우 중요한 특성이다.

5. 핵심 기능 구현: 단계별 가이드 및 코드 예제

이 장에서는 앞서 설계한 아키텍처를 바탕으로 AMR의 핵심 기능을 구현하는 구체적인 방법과 코드 예제를 제시한다. Torizon의 컨테이너 환경에서 하드웨어와 ROS 2 소프트웨어 스택을 연결하는 실질적인 과정을 다룬다.

5.1 ros2_control을 위한 커스텀 하드웨어 인터페이스 구현

ros2_control 프레임워크를 사용하기 위해서는 로봇의 물리적 하드웨어와 통신하는 커스텀 하드웨어 인터페이스를 구현해야 한다. 이는 hardware_interface::SystemInterface 클래스를 상속받아 작성하는 C++ 플러그인이다.26

5.1.1 하드웨어 인터페이스 클래스 구현

차동 구동 로봇을 위한 하드웨어 인터페이스는 최소한 두 개의 바퀴 조인트에 대한 상태(위치, 속도)를 읽고, 명령(속도)을 쓰는 기능을 제공해야 한다. 다음은 그 기본 구조이다.

// diffbot_system.hpp
#include "hardware_interface/system_interface.hpp"
#include "rclcpp/rclcpp.hpp"
#include "your_serial_library.hpp" // 실제 시리얼 통신 라이브러리

namespace diffbot_hardware
{
class DiffBotSystemHardware : public hardware_interface::SystemInterface
{
public:
// 표준 인터페이스 함수들
hardware_interface::CallbackReturn on_init(const hardware_interface::HardwareInfo & info) override;
std::vector<hardware_interface::StateInterface> export_state_interfaces() override;
std::vector<hardware_interface::CommandInterface> export_command_interfaces() override;
hardware_interface::CallbackReturn on_activate(const rclcpp_lifecycle::State & previous_state) override;
hardware_interface::CallbackReturn on_deactivate(const rclcpp_lifecycle::State & previous_state) override;

// 주기적으로 호출되는 핵심 함수
hardware_interface::return_type read(const rclcpp::Time & time, const rclcpp::Duration & period) override;
hardware_interface::return_type write(const rclcpp::Time & time, const rclcpp::Duration & period) override;

private:
// 모터 드라이버와의 시리얼 통신 객체
SerialPort serial_port_;

// 각 조인트의 상태와 명령을 저장할 변수
double hw_left_wheel_command_;
double hw_right_wheel_command_;
double hw_left_wheel_state_pos_;
double hw_right_wheel_state_vel_;
double hw_right_wheel_state_pos_;
double hw_right_wheel_state_vel_;
};
} // namespace diffbot_hardware

• on_init(): URDF에서 하드웨어 파라미터(예: 시리얼 포트 이름, 보드레이트)를 읽어와 초기화한다.

• export_state_interfaces(): 하드웨어가 제공하는 상태 정보(예: left_wheel_joint/position, left_wheel_joint/velocity)를 ros2_control 프레임워크에 등록한다.

• export_command_interfaces(): 하드웨어가 수신할 수 있는 명령 정보(예: left_wheel_joint/velocity)를 등록한다.

• read(): 컨트롤러 관리자에 의해 주기적으로 호출된다. 이 함수 내에서 시리얼 포트를 통해 모터 드라이버로부터 실제 바퀴의 인코더 값(위치)과 속도를 읽어와 hw_*_state_* 변수들을 업데이트해야 한다.38

• write(): read() 직후 호출된다. diff_drive_controller와 같은 컨트롤러가 계산한 목표 속도 명령(hw_*_command_)을 받아, 이를 모터 드라이버가 이해할 수 있는 프로토콜로 변환하여 시리얼 포트로 전송한다.

5.1.2 URDF 및 컨트롤러 설정

하드웨어 인터페이스 플러그인을 ros2_control이 인식하고 사용하게 하려면, 로봇의 URDF 파일과 컨트롤러 설정 YAML 파일을 작성해야 한다.

URDF (<robot_name>.ros2_control.xacro):

<ros2_control name="DiffBot" type="system">
<hardware>
<plugin>diffbot_hardware/DiffBotSystemHardware</plugin>
<param name="serial_port">/dev/ttyACM0</param>
<param name="baud_rate">57600</param>
</hardware>
<joint name="left_wheel_joint">
<command_interface name="velocity">
<param name="min">-10.0</param>
<param name="max">10.0</param>
</command_interface>
<state_interface name="position"/>
<state_interface name="velocity"/>
</joint>
<joint name="right_wheel_joint">
<command_interface name="velocity">
<param name="min">-10.0</param>
<param name="max">10.0</param>
</command_interface>
<state_interface name="position"/>
<state_interface name="velocity"/>
</joint>
</ros2_control>

이 파일은 사용할 하드웨어 인터페이스 플러그인의 이름(diffbot_hardware/DiffBotSystemHardware)과 각 조인트가 제공하는 명령/상태 인터페이스를 명시한다.27

컨트롤러 YAML (controllers.yaml):

controller_manager:
ros__parameters:
update_rate: 100 # Hz

diff_drive_controller:
type: diff_drive_controller/DiffDriveController

joint_state_broadcaster:
type: joint_state_broadcaster/JointStateBroadcaster

diff_drive_controller:
ros__parameters:
left_wheel_names: ["left_wheel_joint"]
right_wheel_names: ["right_wheel_joint"]
wheel_separation: 0.4
wheel_radius: 0.1
publish_rate: 50.0
odom_frame_id: "odom"
base_frame_id: "base_link"

이 파일은 컨트롤러 관리자를 설정하고, diff_drive_controller와 joint_state_broadcaster를 로드하도록 지시한다. 또한, diff_drive_controller에 필요한 로봇의 기구학적 파라미터(바퀴 간 거리, 바퀴 반지름 등)를 제공한다.28

5.2 컨테이너 내 하드웨어 접근 설정: 안전하고 세분화된 제어

AMR 개발의 가장 큰 장애물 중 하나는 컨테이너라는 격리된 환경에서 물리적 하드웨어에 접근하는 것이다. 보안을 심각하게 저해하는 --privileged 모드를 사용하는 대신, docker-compose.yml 파일에서 제공하는 세분화된 옵션을 사용하여 필요한 최소한의 권한만 부여하는 것이 매우 중요하다.39

다음 표는 주요 주변장치별로 권장되는 안전한 접근 설정 방법을 요약한 것이다.

이러한 설정은 docker-compose.yml 파일의 해당 서비스 정의 내에 추가된다. 예를 들어, UART와 USB 카메라를 사용하는 서비스는 다음과 같이 구성할 수 있다.

services:
amr-app:
build:.
network_mode: host
devices:
- /dev/ttyACM0:/dev/ttyACM0
- /dev/video0:/dev/video0
group_add:
- dialout
- video

5.3 slam_toolbox와 Nav2를 이용한 자율 주행 설정

모든 하드웨어 인터페이스와 센서 드라이버가 준비되면, 이들을 slam_toolbox 및 Nav2와 통합하여 자율 주행 시스템을 완성할 수 있다. 이는 ROS 2의 launch 시스템을 통해 이루어진다.

5.3.1 통합 Launch 파일 작성

통합 launch.py 파일은 AMR 시스템을 구성하는 모든 노드를 체계적으로 실행하고 파라미터를 전달하는 역할을 한다.

# bringup.launch.py
from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
# 1. 로봇 상태 발행 노드 (URDF 기반)
robot_state_publisher_node = Node(...)

# 2. 컨트롤러 관리자 노드 (ros2_control)
controller_manager_node = Node(
package="controller_manager",
executable="ros2_control_node",
parameters=["path/to/controllers.yaml"],
...
)

# 3. 센서 드라이버 노드 (예: LiDAR, 카메라)
lidar_node = Node(...)
realsense_node = Node(...)

# 4. SLAM 또는 내비게이션 노드
# 지도 생성 시:
slam_toolbox_node = Node(
package="slam_toolbox",
executable="async_slam_toolbox_node",
parameters=["path/to/slam_params.yaml"],
...
)
# 내비게이션 시:
# nav2_bringup 패키지의 launch 파일을 IncludeLaunchDescription으로 포함

return LaunchDescription([
robot_state_publisher_node,
controller_manager_node,
lidar_node,
realsense_node,
slam_toolbox_node,
#... 기타 필요한 노드들
])

5.3.2 RViz2를 통한 시각화 및 테스트

시스템이 실행되면, RViz2를 사용하여 모든 것이 정상적으로 동작하는지 확인하고 테스트할 수 있다.

1. RViz2 실행: ros2 run rviz2 rviz2 명령어로 RViz2를 실행한다.

2. 디스플레이 추가:

• TF: 로봇의 모든 좌표계(map, odom, base_link, laser_frame 등)가 올바르게 연결되어 있는지 시각적으로 확인한다.

• Map (/map 토픽): slam_toolbox가 생성하는 지도를 실시간으로 확인한다.17

• LaserScan (/scan 토픽): LiDAR 센서 데이터가 정상적으로 수신되는지 확인한다.

• RobotModel: URDF 파일로부터 로봇의 3D 모델을 시각화한다.

3. 지도 생성: 로봇을 수동으로 조종(teleoperation)하여 환경을 탐색한다. RViz2의 Map 디스플레이에 점차 지도가 그려지는 것을 확인할 수 있다.

4. 내비게이션 테스트: 지도가 완성되면 slam_toolbox를 위치 추정 모드로 전환하거나, 저장된 지도를 map_server로 불러온 후 amcl 노드를 실행한다. RViz2의 ‘2D Pose Estimate’ 도구로 로봇의 초기 위치를 알려주고, ‘Nav2 Goal’ 도구로 목표 지점을 클릭하면 Nav2 스택이 경로를 계획하고 로봇이 자율적으로 주행을 시작한다.

이 과정을 통해 개발자는 복잡한 AMR 시스템의 각 구성 요소가 어떻게 상호작용하는지 직관적으로 이해하고, 문제를 신속하게 진단할 수 있다.

6. 고급 주제 및 실용적 고려사항

프로토타입을 넘어 안정적이고 성능이 뛰어난 상용 AMR 제품을 만들기 위해서는 몇 가지 고급 주제와 실용적인 고려사항을 다루어야 한다. 이 장에서는 실시간 성능 최적화, 원격 모니터링, 그리고 양산 배포를 위한 시스템 이미지 커스터마이징에 대해 논한다.

6.1 실시간 성능 분석 및 최적화

AMR의 제어 루프는 수 밀리초(ms) 단위의 정밀한 시간 제어를 요구할 수 있다. ROS 2 통신의 지연 시간(latency)과 지터(jitter, 지연 시간의 변동성)는 시스템의 안정성과 직결된다. 이를 최적화하기 위한 몇 가지 접근법이 있다.

실시간 RMW(ROS Middleware) 구현체 사용: ROS 2는 DDS를 통해 통신하며, RMW 계층을 통해 다양한 DDS 구현체를 플러그인처럼 교체할 수 있다. 기본 RMW인 Fast DDS도 우수한 성능을 보이지만, 실시간 성능에 특화된 Eclipse CycloneDDS는 종종 더 낮은 지연 시간과 지터를 제공하는 것으로 알려져 있다.41 RMW_IMPLEMENTATION 환경 변수를 rmw_cyclonedds_cpp로 설정하는 것만으로 간단하게 RMW를 전환할 수 있다.4

CycloneDDS 튜닝: CycloneDDS는 XML 설정 파일을 통해 상세한 튜닝이 가능하다.43 예를 들어, NetworkInterface 태그를 사용하여 통신에 사용할 특정 네트워크 인터페이스(예: eth0)를 명시적으로 지정할 수 있다. 이는 Wi-Fi와 유선 이더넷이 공존하는 환경에서 DDS 트래픽이 의도치 않은 인터페이스로 유출되는 것을 방지하고, 통신의 예측 가능성을 높인다. 또한, AllowMulticast 설정을 false로 변경하여 멀티캐스트 대신 유니캐스트 통신을 강제함으로써, 특정 네트워크 환경에서 발생할 수 있는 문제를 예방할 수 있다.

ros2_tracing을 이용한 성능 분석: ros2_tracing은 LTTng 커널 트레이서를 사용하여 ROS 2 시스템의 내부 동작을 나노초(ns) 단위로 추적하고 분석하는 강력한 도구이다.44 이를 통해 콜백 실행 시간, 메시지가 발행되어 구독되기까지의 종단 간 지연 시간, 스레드 스케줄링 이벤트 등을 상세하게 분석할 수 있다. 개발자는 ros2_tracing으로 얻은 데이터를 시각화하여 시스템의 병목 구간을 정확히 식별하고, 특정 노드의 우선순위를 조정하거나 알고리즘을 개선하는 등 데이터 기반의 성능 최적화를 수행할 수 있다.45

6.2 Torizon의 디바이스 모니터링과 ROS 2 노드 상태 모니터링 연동

Torizon Cloud는 CPU, 메모리, 네트워크 사용량과 같은 시스템 수준의 메트릭을 기본적으로 모니터링하는 기능을 제공한다.1 그러나 상용 AMR 운영에서는 시스템 리소스뿐만 아니라, ROS 2 애플리케이션 자체의 상태를 파악하는 것이 매우 중요하다. 예를 들어, Nav2 스택이 정상적으로 활성화되었는지, SLAM의 위치 추정 신뢰도가 일정 수준 이상인지 등을 원격으로 확인해야 한다.

이를 위해 Torizon의 디바이스 모니터링 기능을 확장하여 ROS 2 애플리케이션 수준의 메트릭을 수집하는 아키텍처를 구축할 수 있다.

1. 메트릭 발행 노드 개발: ROS 2 애플리케이션 내에 특정 토픽(예: /diagnostics)을 구독하거나, 각 노드의 상태를 주기적으로 폴링(polling)하여 핵심 성능 지표(KPI)를 수집하는 전용 모니터링 노드를 개발한다. 수집할 메트릭의 예시는 다음과 같다:

• Nav2 스택의 현재 상태 (활성, 비활성, 복구 중)

• amcl 또는 slam_toolbox가 추정한 위치의 공분산(covariance) 값

• 제어 루프의 실제 실행 주기(Hz)

• 카메라 또는 LiDAR의 데이터 수신 빈도

2. 메트릭 파일 출력: 모니터링 노드는 수집한 메트릭을 Torizon의 모니터링 에이전트가 읽을 수 있는 형식(예: JSON, Prometheus 텍스트 형식)으로 파일에 주기적으로 기록한다. 이 파일은 컨테이너의 볼륨 마운트를 통해 호스트 시스템의 특정 디렉토리(예: /var/monitoring)에 저장된다.

3. Torizon 모니터링 에이전트 설정: Torizon의 모니터링 에이전트 설정을 커스터마이징하여, 위에서 생성된 파일을 읽고 그 내용을 Torizon Cloud로 전송하도록 구성한다.

이러한 연동을 통해 운영자는 Torizon Cloud 대시보드에서 하드웨어 리소스 상태와 ROS 2 애플리케이션의 건강 상태를 통합적으로 모니터링할 수 있다. 이는 고장 예측 및 원격 진단의 효율성을 크게 향상시켜, AMR 플릿의 가동 시간을 극대화하는 데 기여한다.

6.3 양산 및 배포를 위한 TorizonCore Builder 활용법

개발 단계에서는 소스 코드, 빌드 도구, 디버거 등 다양한 요소가 포함된 컨테이너를 사용하지만, 실제 양산 제품에 배포되는 이미지는 최대한 가볍고 안전해야 한다. TorizonCore Builder는 이러한 프로덕션용 Torizon OS 이미지를 생성하고 커스터마이징하기 위한 명령줄 도구이다.1

TorizonCore Builder의 주요 활용 사례는 다음과 같다:

• 애플리케이션 컨테이너 사전 탑재 (Pre-provisioning): 개발이 완료된 최종 AMR 애플리케이션 컨테이너 이미지를 Torizon OS 이미지 내에 미리 포함시킬 수 있다. docker-compose.yml 파일을 함께 제공하면, 로봇이 처음 부팅될 때 별도의 설정 없이 자동으로 애플리케이션 컨테이너가 실행되도록 할 수 있다. 이는 양산 라인에서 각 장치를 프로비저닝하는 과정을 극도로 단순화한다.

• 시스템 설정 커스터마이징: Wi-Fi 자격 증명, 네트워크 설정, 커스텀 커널 모듈, 장치 트리 오버레이(device-tree overlay) 등 특정 하드웨어나 운영 환경에 필요한 설정 파일들을 이미지에 통합할 수 있다.6

• 커스텀 스플래시 스크린 적용: 부팅 시 회사 로고와 같은 커스텀 스플래시 스크린을 표시하도록 이미지를 수정하여 제품의 브랜딩을 강화할 수 있다.6

TorizonCore Builder는 tcbuild.yaml이라는 설정 파일을 통해 이러한 모든 커스터마이징 작업을 관리한다. 개발자는 이 파일을 버전 관리 시스템(예: Git)으로 관리하여, 프로덕션 이미지의 변경 사항을 체계적으로 추적하고 재현 가능한 빌드를 보장할 수 있다. 이러한 접근 방식은 개발에서 운영으로의 전환을 원활하게 만들고, AMR 제품의 신뢰성과 일관성을 보장하는 핵심적인 DevOps 실천법이다.

7. 결론: 성공적인 AMR 제품화를 위한 전략적 제언

7.1 개발 패러다임의 핵심 요약: 컨테이너화, 하드웨어 추상화, DevOps

본 보고서는 Toradex Torizon 플랫폼과 ROS 2 Humble을 결합하여 산업용 AMR을 개발하는 전 과정에 대한 심층적인 분석을 제공하였다. 분석 결과, 이 기술 조합의 성공은 단순히 두 기술을 사용하는 것을 넘어, 세 가지 핵심적인 현대 소프트웨어 개발 패러다임을 내재화하는 데 달려 있음을 확인하였다.

1. 컨테이너화 (Containerization): Docker를 통한 애플리케이션의 격리 및 패키징은 AMR 개발의 복잡한 의존성 문제를 해결하고, 개발-테스트-배포 환경의 일관성을 보장하는 근본적인 해결책이다. 이는 ROS 2의 모듈식 아키텍처와 결합하여, 각 기능을 독립적으로 개발, 테스트, 업데이트할 수 있는 마이크로서비스 형태의 로봇 소프트웨어 아키텍처를 가능하게 한다.

2. 하드웨어 추상화 (Hardware Abstraction): ros2_control 프레임워크는 로봇의 물리적 구동계와 제어 알고리즘 간의 의존성을 분리하는 표준화된 접근법을 제시한다. 이는 소프트웨어의 재사용성을 극대화하고, 새로운 하드웨어 플랫폼으로의 이식을 용이하게 하여 AMR 제품 라인업의 유연성과 확장성을 보장한다.

3. DevOps (Development and Operations): Torizon 플랫폼은 그 자체로 임베디드 시스템을 위한 DevOps 플랫폼이다. VS Code 통합을 통한 신속한 개발-디버그-배포 사이클, TorizonCore Builder를 통한 재현 가능한 프로덕션 이미지 빌드, 그리고 Torizon Cloud를 통한 OTA 업데이트 및 원격 모니터링은 개발(Dev)과 운영(Ops)의 경계를 허물고, 제품의 전체 수명 주기에 걸쳐 지속적인 개선과 안정적인 유지보수를 가능하게 하는 핵심 요소이다.

이 세 가지 패러다임은 상호 유기적으로 연결되어, AMR 개발의 기술적 부채를 줄이고, 시장 출시 기간을 단축하며, 최종 제품의 품질과 신뢰성을 향상시키는 선순환 구조를 형성한다.

7.2 프로젝트 단계별 기술적 의사결정을 위한 최종 권고안

AMR 개발 프로젝트를 성공적으로 이끌기 위해, 각 단계별로 다음과 같은 기술적 의사결정을 내릴 것을 권고한다.

• 프로토타이핑 단계:

• Toradex에서 제공하는 표준 Torizon OS 이미지와 공식 ROS 2 Humble Docker 이미지를 사용하여 신속하게 개발 환경을 구축하라.

• VS Code와 Torizon IDE Extension을 적극 활용하여 개발, 배포, 디버깅의 반복 주기를 최소화하라.

• ros2_control의 데모 예제(ros2_control_demos)를 기반으로 커스텀 하드웨어 인터페이스 개발을 시작하여 프레임워크에 대한 이해도를 높여라.48

• 필드 테스트 단계:

• --privileged 모드 사용을 완전히 배제하고, 본 보고서의 표 5.1을 참조하여 필요한 하드웨어에 대한 최소한의 접근 권한만을 부여하는 보안 정책을 수립하라.

• 실시간 성능이 중요한 제어 루프를 위해 CycloneDDS와 같은 실시간 RMW를 적용하고, ros2_tracing을 이용하여 성능 병목을 식별하고 최적화하라.

• Torizon Cloud의 디바이스 모니터링 기능을 활용하여 실제 운영 환경에서의 시스템 리소스 사용량과 안정성을 데이터 기반으로 분석하라.

• 양산 및 유지보수 단계:

• TorizonCore Builder를 사용하여 개발 도구가 제거된 경량화된 프로덕션 전용 OS 이미지를 생성하라. 최종 애플리케이션 컨테이너와 설정을 이미지에 사전 탑재하여 양산 공정을 단순화하라.

• Torizon Cloud의 OTA 업데이트 기능을 활용하여 전체 플릿에 대한 보안 패치 및 기능 업데이트를 위한 안정적이고 자동화된 파이프라인을 구축하라.

• ROS 2 애플리케이션의 핵심 상태 지표를 Torizon Cloud로 전송하는 커스텀 모니터링 시스템을 구축하여, 예방 정비 및 신속한 원격 지원 체계를 마련하라.

7.3 향후 전망: Torizon과 ROS 2 생태계의 발전 방향

Torizon과 ROS 2 생태계는 지속적으로 발전하고 있으며, 이는 향후 AMR 개발에 더 많은 기회를 제공할 것이다.

Toradex는 기능 안전(Functional Safety)이 요구되는 애플리케이션을 위해 QNX와 같은 안전 인증 RTOS와의 협력을 강화하고 있다.50 이는 향후 Torizon 플랫폼이 ISO 10218과 같은 산업용 로봇 안전 표준을 준수해야 하는 고위험 환경의 AMR 개발에도 적용될 수 있는 가능성을 시사한다. 또한, 리소스가 제한된 마이크로컨트롤러(MCU)에서 ROS 2 노드를 실행하는 마이크로-ROS(micro-ROS)와의 통합은 37, 엔드-이펙터나 소형 센서 모듈까지 ROS 2 생태계로 포괄하는 더욱 분산되고 효율적인 AMR 아키텍처를 가능하게 할 것이다.

ROS 2 생태계 역시 Nav2의 지속적인 기능 개선, 새로운 SLAM 및 비전 알고리즘의 등장, AI/ML 통합 가속화를 통해 더욱 지능적이고 강력한 AMR 개발을 지원할 것이다.

결론적으로, Torizon의 산업용 DevOps 플랫폼과 ROS 2의 개방형 로보틱스 프레임워크의 결합은 AMR 개발의 현재와 미래를 위한 가장 강력하고 전략적인 선택 중 하나이다. 이 조합을 통해 개발자는 기술적 복잡성에 매몰되지 않고, 시장이 요구하는 혁신적이고 신뢰성 높은 AMR 제품을 성공적으로 만들어낼 수 있을 것이다.

8. 참고 자료

1. Torizon - Simplifying the Development and Operation of Linux IoT Devices - Toradex, https://www.toradex.com/torizon
2. Torizon OS - Easy-to-use Industrial Linux Software Platform - Toradex, https://www.toradex.com/operating-systems/torizon-os
3. Torizon: IIoT, OTA, Industrial Linux, Remote updates, Device Monitoring, https://www.torizon.io/
4. Torizon & ROS2: Smarter Embedded Robotics Development, https://www.torizon.io/blog/torizon-ros2-empower-robotic-projects
5. Torizon Cloud Overview - Toradex Developer Center, https://developer.toradex.com/torizon/torizon-platform/torizon-platform-services-overview/
6. Torizon OS Technical Overview | Toradex Developer Center, https://developer.toradex.com/torizon/torizoncore/torizoncore-technical-overview/
7. ROS documentation, https://docs.ros.org/
8. Installation — ROS 2 Documentation: Humble documentation, https://docs.ros.org/en/humble/Installation.html
9. Open-source Industrial Embedded Linux OS - Torizon OS, https://www.torizon.io/torizon-os
10. Understanding real-time programming — ROS 2 Documentation: Foxy documentation, https://docs.ros.org/en/foxy/Tutorials/Demos/Real-Time-Programming.html
11. Torizon real time - Technical Support - Toradex Community, https://community.toradex.com/t/torizon-real-time/13814
12. Torizon IDE Extension - Visual Studio Marketplace, https://marketplace.visualstudio.com/items?itemName=Toradex.apollox-vscode
13. Visual Studio Code IDE Extension - Toradex Developer Center, https://developer.toradex.com/torizon/application-development/ide-extension/
14. TorizonCore Builder VS Code Integration - Toradex Developer Center, https://developer.toradex.com/torizon/os-customization/torizoncore-builder-vs-code-integration/
15. Running ROS 2 nodes in Docker [community-contributed], https://docs.ros.org/en/foxy/How-To-Guides/Run-2-nodes-in-single-or-separate-docker-containers.html
16. SLAM and Nav2 Implementation for Custom ROS2 Robots | Medium - Ibrahim Bin Mansur, https://ibrahimmansur4.medium.com/slam-and-nav2-for-custom-robots-in-ros2-905400437ae1
17. ROS2 Nav2 - Generate a Map with slam_toolbox - The Robotics Back-End, https://roboticsbackend.com/ros2-nav2-generate-a-map-with-slam_toolbox/
18. ROS Wrapper for Intel(R) RealSense(TM) Cameras - GitHub, https://github.com/IntelRealSense/realsense-ros
19. Setup ROS 2 with VSCode and Docker [community-contributed] - ROS documentation, https://docs.ros.org/en/iron/How-To-Guides/Setup-ROS-2-with-VSCode-and-Docker-Container.html
20. An Updated Guide to Docker and ROS 2 - Robotic Sea Bass, https://roboticseabass.com/2023/07/09/updated-guide-docker-and-ros2/
21. ROS 2 and VSCode - PickNik Robotics, https://picknik.ai/vscode/docker/ros2/2024/01/23/ROS2-and-VSCode.html
22. ErickKramer/ros2_with_vscode: Vscode setup that I use to work with ROS2 - GitHub, https://github.com/ErickKramer/ros2_with_vscode
23. Unlocking Enhanced Development Experience: Creating Custom Configurations for VSCode Extensions - The Robotics Space, https://www.theroboticsspace.com/blog/VS-Code-ROS-Configurations/
24. Welcome to the ros2_control documentation - Humble!, https://control.ros.org/humble/index.html
25. Welcome to the ros2_control documentation! — ROS2_Control: Rolling Oct 2025 documentation, https://control.ros.org/
26. ROS2 Control with the JetBot Part 2: Building a ros2_control System | Mike Likes Robots, https://mikelikesrobots.github.io/blog/jetbot-motors-pt2/
27. ROS 2 Control for Custom Robots: Mastering Real-Time Robot Control - ThinkRobotics.com, https://thinkrobotics.com/blogs/learn/ros-2-control-for-custom-robots-mastering-real-time-robot-control
28. diff_drive_controller — ROS2_Control: Humble Oct 2025 documentation, https://control.ros.org/humble/doc/ros2_controllers/diff_drive_controller/doc/userdoc.html
29. A list of ROS2 supported sensors for robots - The Construct, https://www.theconstruct.ai/list-ros2-supported-sensors-for-robots/
30. ROS Compatible Sensors - RobotShop, https://www.robotshop.com/collections/ros-parts-compatible-sensors
31. SICKAG/sick_scan_xd: A versatile driver for a wide range of SICK LiDAR and RADAR devices, providing support for both Linux (native, ROS 1, ROS 2) and Windows (native, ROS 2) platforms. - GitHub, https://github.com/SICKAG/sick_scan_xd
32. Package ouster-lidar-ros2-driver-humble - GitHub, https://github.com/orgs/vortexntnu/packages/container/package/ouster-lidar-ros2-driver-humble
33. realsense2_camera - ROS Wiki, https://wiki.ros.org/realsense2_camera
34. Realsense on Jammy and ROS2-Humble - Arcos-Lab Wiki, https://wiki.arcoslab.org/tutorials/realsense_jammy_humble
35. slam_toolbox: Humble 2.6.10 documentation, https://docs.ros.org/en/humble/p/slam_toolbox/
36. slam_toolbox - ROS Package Overview, https://index.ros.org/p/slam_toolbox/
37. Welcome to the ROS Community, https://www.ros.org/blog/community/
38. Using ros2 control hardware interface make the communication slow, https://robotics.stackexchange.com/questions/113424/using-ros2-control-hardware-interface-make-the-communication-slow
39. Best Practices with Peripheral Access | Toradex Developer Center, https://developer.toradex.com/torizon/application-development/use-cases/peripheral-access/best-practices-with-hardware-access/
40. Passing a USB camera though docker, only works with –privileged - Toradex Community, https://community.toradex.com/t/passing-a-usb-camera-though-docker-only-works-with-privileged/26724
41. Performance Evaluation of Real-Time ROS2 Robotic Control in a Time-Synchronized Distributed Network - ResearchGate, https://www.researchgate.net/publication/355155309_Performance_Evaluation_of_Real-Time_ROS2_Robotic_Control_in_a_Time-Synchronized_Distributed_Network
42. Eclipse Cyclone DDS — ROS 2 Documentation, https://docs.ros.org/en/foxy/Installation/DDS-Implementations/Working-with-Eclipse-CycloneDDS.html
43. Cyclone-DDS - ROS 2 Real-Time Working Group, https://ros-realtime.github.io/Guides/Configure-RMW-Implementation/Cyclone-DDS.html
44. Tutorials — ROS 2 Documentation: Humble documentation, https://docs.ros.org/en/humble/Tutorials.html
45. irobot-ros/ros2-performance: Framework to evaluate peformance of ROS 2 - GitHub, https://github.com/irobot-ros/ros2-performance
46. ROS 2 Performance Benchmarking - Open Robotics Discourse, https://discourse.openrobotics.org/t/ros-2-performance-benchmarking/44382
47. Application Software Installation on Torizon OS - Toradex Developer Center, https://developer.toradex.com/torizon/application-development/application-software-installation-on-torizon-os/
48. ros-controls/ros2_control_demos: This repository aims at providing examples to illustrate ros2_control and ros2_controllers - GitHub, https://github.com/ros-controls/ros2_control_demos
49. Demos — ROS2_Control: Humble Oct 2025 documentation, https://control.ros.org/humble/doc/ros2_control_demos/doc/index.html
50. Toradex & QNX Collaborate on Industrial Robotics Safety, https://www.toradex.com/news/toradex-qnx-robotic-safety-industry-5.0
51. Toradex and QNX Partner to Streamline ISO 10218 Compliance for Industrial Robotics, https://embeddedcomputing.com/technology/security/iec-iso-other-standards/toradex-and-qnx-partner-to-streamline-iso-10218-compliance-for-industrial-robotics